Minutes, IBIS Quality Committee 01 September 2009 11-12 AM EST (8-9 AM PST) ROLL CALL Adam Tambone * Anders Ekholm, Ericsson Barry Katz, SiSoft Benny Lazer Benjamin P Silva Bob Cox, Micron * Bob Ross, Teraspeed Consulting Group Brian Arsenault David Banas, Xilinx * Eckhard Lenski, Nokia Siemens Networks Eric Brock Guan Tao, Huawei Technologies Gregory R Edlund Hazem Hegazy Huang Chunxing, Huawei Technologies John Figueroa John Angulo, Mentor Graphics Katja Koller, Nokia Siemens Networks Kevin Fisher Kim Helliwell, LSI Logic Lance Wang, IOMethodology Lynne Green * Mike LaBonte, Cisco Systems Mike Mayer, SiSoft * Moshiul Haque, Micron Technology Muniswarareddy Vorugu, ARM Ltd * Pavani Jella, TI Peter LaFlamme Randy Wolff, Micron Technology Radovan Vuletic, Qimonda Robert Haller, Enterasys Roy Leventhal, Leventhal Design & Communications Sherif Hammad, Mentor Graphics Todd Westerhoff, SiSoft Tom Dagostino, Teraspeed Consulting Group Kazuyoshi Shoji, Hitachi Sadahiro Nonoyama Liqun, Huawei Everyone in attendance marked by * NOTE: "AR" = Action Required. -----------------------MINUTES --------------------------- Mike LaBonte conducted the meeting. Call for opens and patent disclosures: - Bob: Would like to discuss static overshoot - Mike: Would like to discuss final IQ 2.0 URL - No one declared a patent. AR Review: - Mike post IQ PDF to agreed URL and email ibis-quality list - Done - Mike and Bob announce release of IQ spec for Open Forum review - Done - Not much feedback - Bob pointed out the length of the table of contents - Mike change web site to avoid using frames - Ongoing New items: AR: Mike try to reduce TOC to 2 pages Should we have a link to the review spec? - We looked at the IBIS Quality web page AR: Mike link to new IQ 2.0 document on our web page Discussion of static overshoot: - We looked at IQ 5.2.5. {LEVEL 2} [Model Spec] S_Overshoot sub-parameters complete and match data sheet - Bob: If the buffer is 3-state the overshoot limit is for protection, not function - Anders: IBIS assumes it is for function - We passed a BIRD - Mike: Is this for outputs or inputs? - Bob: It should apply for all modes - Anders: Agree - Bob: The parser warns on static_overshoot for an output-only device - Since IBISCHK 3 - A 3-state could be harmed by a large excursion - We should remove this warning - Currently this warning would be waived - Anders: 5.2.5 does not talk about inputs and outputs - Maybe a change would help force the BUG - We looked at [Model Spec] S_overshoot* in the IBIS 5 spec - It does not discuss input vs. output - Mike: So the parser is wrong - Bob: The IQ spec implies it applies to input capable buffers only - Mike: The first sentence does not say "must" or "should" - It says "The functional limits may not be found in some data sheets" - We should change "All input and I/O buffers have" to "All buffers should have" - Bob: It may be that overshoot limits are not known for 90% of buffers - Anders: But we are saying that this check must be passed for level 2 - Anders: The parser is stopping people from putting in s_overshoot - Bob: The Visual IBIS tool uses IBISCHK 3.2 - Mike checked and found it using 4.1 - Eckhard: Some files pass the official 4.1 IBISCHK but Visual IBIS fails them - Bob: It would be nice if they adopted 4.2 - Vendors are free to support whatever they want - It would be best if they had a "standard IBIS checking" option - Mike: It would be best to say that no waiver is required due to the bug - Moshiul: Other checks have the same problem, especially with older parsers - There was a problem with differential pins - Mike: This is different because we know the parser will change, but has not yet - Bob: Vendors will decide whether to use X - Mike: X means something inside is important enough to look inside before using - I would still put in the comment - We added "should" to 5.2.5 - Mike: Can we remove "input and I/O"? - Anders: Only if we want to make many files be level 2 - Bob: They could be level 2 with an exception - Mike: What are the reasons IC vendors tend not to provide this? - Moshiul: Some IBIS tools don't use it - DDR specifies it differently - The info comes from JEDEC - Pavani: We only have absolute maximum ratings - Some customers asked us to use absolute max for S_overshoot - It is probably more critical for DDR - Bob: JEDEC now species area under a curve in [Receiver Thresholds] - Mike: That is dynamic overshoot, not static - Anders: We do get separate specs for functional and protection limits - Bob: Bob Haller wanted all IBIS sub-params present - Anders: This does not affect the waveforms produced - It is not as critical to accuracy - Mike: We do check overshoot but have to find it if IBIS doesn't have it Meeting ended at 12:12 PM Eastern Time.